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(54) System for providing a trustworthy user interface 



(57) The preferred embodiment of the invention 
comprises a computer system which employs a trusted 
display processor (260). which has a trusted processor 
(300) and trusted memory (305, 315, 335, 345) physi- 
cally and functionally distinct from the processor and 
memory ol the computer system. The trusted display 
processor (260) is immune to unauthorised modification 
or inspection of internal data It is physical to prevent 
forgery, tamper-resistant to prevent counterfeiting, and 



has crypto functions (340) to securely communicate at 
a distance. The trusted display processor (260) interacts 
with a user's smartcard ( 1 22) in order to extract and dis- 
play a trusted image, or seal (1000), generate a digital 
signature of the bitmap of a document image and control 
the video memory (315) so that other processes of the 
computer system cannot subvert the image during the 
signing process. The user interacts with the trusted dis- 
play processor via a trusted switch (135). 
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(or pull-up) menus. . ^ . the internet known as B e-cornmerce , l there has been 

OoSs] ^increaseincc^^^ 

much interest in the prior art on ^^^^^^^^Z^^ over .he Internet, without the need 
rt is perceived to be important .or users to ^^^"^S^ potential tor fraud and manipulation of 
,or the current standard hanc^igned ^^^s^Sll unKparUes on a widespread sea* 
electronic data, in such proposal held back. The fundamental issue is one 

o?;r£rr^^^ 

computer platforms. Predomhantly ^^"^^^^."sTerns, andare not built in to the funda- 
the security features are not inherently ^^^S^SSSS^i^ have already appeared on the 
mental hardware components of the conpuUng P**™2™ ^ fe a smarteard reader on the 

marl«twhichinc.u*asmar^ 

computer. PresenHy. such, smartcards are at the level* b«ng prior art schemes go some way to 

in some cases are integrated into a em of f^ te < ^^^J u ^hess gained by prior art schemes 

990M56.9, filed at the UK Patent Office on 5 ^^^^^L^ a computing platform which has 
feference, there is dtedosed a concept of ™££S2£ ^ZgZiSSZSZ JSSed with such 
a trusted component- in the form of a ^^^"^^^^j^ « to say, where the first and second 

trusted component is present, because: 

. Auserofecornp^ngentHyhash^rcc^^ 
thehUrity^securttyrithe^ 
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• Each entity is confident that the other entity is in fact the entity which rt purports to be; 

• Where one or both of the entities represent a party to a transaction, e.g. a data transfer transaction, because of 
the in-built trusted component, third party entities interacting with the entity have a high degree of confidence that 

s the entity does in fact represent such a party; 

• The trusted component increases the inherent security of the entity itself, through verification and monitoring proc- 
esses implemented by the trusted component; and 

io • The computer entity is more likely to behave in the way it is expected to behave. 

[0008] While the concept of a trusted component as descr&ed in the co-pending application goes a long way to 
provide to a user with a substantial degree of trust in a computer platform, there are still times when the user requires 
an even higher degree of trust in his equipment, for example during an electronic transaction, such as cfgitally signing 
is a document, or transferring funds from the platform to a remote platform 

[0009] As has been indicated above, the conventional method of signing a document is to physically write a signature 
on the medium (usually paper) upon which an Image of a document is reproduced. This method has the advantages 
that it is clear what is being signed, and the signed image Is proof of what was signed. However, ft does not meet the 

needs of e-commerce. ■ f .... 

zo [0O1 o] Nowadays it is also possible to digitally sign a document, using a conventional computer platform and standard 
encryption techniques. In conventional computer platforms, however, the present inventors have appreciated that the 
electronic rendition of a document which is digitally signed is typically not the same rendition of the document that is 
visible to the user. It is therefore possible for a user to unintenttenafly sign data that is dWerent from that which he 
intended to sign. Conversely, it is also possible lor a user to intentionally sign data and later fraudulently claim that the 

2S signod data does not correspond to that displayed to him by the computer platform. Such problems would stll bo the 
present, even if a trusted platform, as descrtoed above, were used. 

[0011] Conventional electronic methods of signing are well known to those skilled in the art Essentially digital data 
is compressed into a digest, for example by the use of a hash function. Then that digest is encrypted by the use of 
some encryption method that has been initialised by a secret key (or simply a 'secref). This is normally done on a 

30 computer platlorm. such as a PC. One implementation is to sign data using a private encryption key held secret on a 
user's smartcard. which is plugged nto a smartcard reader attached to the computer platform. In the specific case of 
a textual document, the digital data may be the file produced by a word processor application, such as Microsoft's 
Notepad, Wordpad. or Word. As usual, the act of signing implies that the signer accepts some legal responstoility for 
the meaning of the data that was signed. ■ 

35 [0O1 2] Hash functions are well-known in the prior art and comprise one way functions which are capable of generating 
a relatively small output data from a relatively large quantity of Input data, where a small change in the input data results 
in a significant change in the output data. Thus, a data file to which is applied a hash function results in a first digest 
data (the output of the hash function). A small change e.g. a single bit of data in the original data file will result in a 
significantly different output when the hash function is reapplied to the modified data file. Thus, a data file comprising 

40 megabytes of data may be input into the hash function and result In a digital output of the order of 128 to 160 bts 
length, as the resultant digest data. Having a relatively small amount of digest data generated from a data file stored 
in the reserved directory is an advantage, since It takes up less memory space and less processing power m the trusted 

component. ^ . . 

[0013] During known signing processes, a user win typically interpret a document as it has been rendered on the 

45 computer's monitor at normal magnification and resolution. In existing applications, the user's smartcard signs data in 
a format that is the representation of the document by the application used to create and/or manipulate the document 
The present inventors believe, however, that there is potential for software to send data to the smartcard that has a 
different meaning from that understood by the user when viewing the screen. This possibility may be sufficient reason 
to introduce doubt into the validity of conventional methods of digitally sign ing electronic representations of documents 

so that are to be interpreted by people. 

Disclosure of the Invention 

[0014] The present invention aims to provide a user with greater trust during a trusted operation by providing a trusted 
55 user interface. 

[0015] In accordance with a first aspect, the present invention provides a data processing system capable of operating 
in a trusted operating mode, the data processing system comprising: 
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main processing means for executing at least one application process; 

a trusted component comprising means for executing a trusted process in a trusted operating mode and means 
for generating user feedback signals; 
at least one user feedback device; and 
s user feedback processing means for receiving said user feedback signals and controlling the user f eecfcack device 
on the basis of the signals, 

wherein the trusted component comprises means for controlling the user feedback processing means to cause 
the user f eecfoack device to provide an indication that the data processing system is operating in a trusted operating 
mode. 

10 

[0016] In preferred embodiments the data processing system comprises secure user input means, h communication 
with the trusted component via a secure communications path, by which a user may securely interact with the trusted 
process. 

[0017] In a prelerred embodiment of the data processing system: 

is 

the main processing means includes means to execute at least one application process and generate signals 
characterising a main image to be displayed; 

the user feedback processing means comprises display processing means for receiving said signals and gener- 
ating respective display signals lor driving a visual display unit to display the main image; and 
20 the trusted component comprises means to acquire ancVor generate trusted image data and means to control to 
display processing means to combine a respective trusted image with at least a portion of the mam image in order 
to indicate to a user that the data processing system is operating in the trusted operating mode. 

[0018] In preferred embodiments the data processing system further comprises a secure token reader for reading 
2& data from and/or writing data to a removable secure token, and a removablo token containing data characterising tho 
trusted image, wherein the trusted component comprises means to receive said data from the secure token. 
[0019] Other aspects and embodiments of the invention wSI become apparent from the following description, claims 
and drawings. 

so Brief Description of the Drawings 

[0020] Embodiments of the present invention will now be described in detail with reference to the accompanying 
drawings, of which: 

3$ Figure 1 is a diagram which illustrates a computer system suitable for operating in accordance with the preferred 
embodiment of the present invention; 

Figure 2 is a diagram which illustrates a hardware architecture of a host computer suitable for operating in accord- 
ance with the preferred embodiment of the present invention; 

Figure 3 is a diagram which illustrates a hardware architecture of a trusted display processor suitable for operating 

40 in accordance with the preferred embodiment of the present invention; 

Figure 4 is a diagram which illustrates a hardware architecture of a smart card processing engine suitable for 
operating in accordance with the preferred errtxxlim^ of the present invention; 

Figure 5 is a diagram which illustrates a functional architecture of a host computer including a trusted display 
processor and a smart card suitable for operating in accordance with the preferred embodiment of the present 

41 invention; 

Figure 6 is a flow diagram which illustrates the steps involved in generating an individual signature of a document; 
Figure 7 is diagram which illustrates the sequence of messages between the trusted display processor and the 
smart card in order lo recover seal image data from the smart card; 

Figure 8 is diagram which illustrates the sequence of messages between the trusted display processor and the 
sc smart card in order to generate a signature of a document image; 

Figure 9 is diagram which illustrates the sequence of messages between the trusted display processor and the 
smart card in order to generate a signature of a summary of the document image signing process; 
Figure 10a is a diagram which illustrates an exemplary trusted image; 

Figures 10b to 10d are diagrams which Blustrate the visual steps in signing a document image; and 
ss Figures 1 0e to 1 0g are diagrams which illustrate alternative ways of highlighting the image of a document to be 

signed. 
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Best Mode For Carrying Out th e Invention. & Industrial Applicability 

r0021l The preferred embodiment utilises a trusted component that most conveniently uses some of the character- • 
sties of the Irusted component' described in the applicants cc-pending European patent application number. 
5 99301100 6 In that application, the trusted component is a hardware device, comprising a processor prograrnmad to 
measurean integrity metric of its hosl computer, compare it with a true value of the integnty metnc and communicate 
the integer S5S2.) <* the host computer to users or other host computers. The significant similarities between 
that irusted component and the trusted component in the preferred embodiment herein are: 

io that they both xise cryptographic processes but preferably do not provide an external interface to those crvpto- 
?h^they P areb^^ 

the knowledge of the legitimate user; and ^ . „_ Jt ^. 

that they both preferably consist of one physical hardware component that is both physically and functionally m- 
is dependent of the host computer on which it resides. 

100221 Such independence is achieved by the trusted component having its own processing capability arrirnemory 
raS TechniqueTrelevanl to tamper-resistance are wen known to those skilled in the art of security, as described 
nihe applicant's cc-pending application. These techniques include methods lor fabricating consents to 'eslsttam- 

j. per^lhods loTdeTecting tampering, and methods for eliminaling data when tampering . "^""J* £ 
predated that, although tamper-proofing is a most desirable feature of the present invention, it does not enter into the 
normal operation of the invention and. as such, is beyond the scope of the present description. 
r0 024] In this description, the term trusted 1 , when used in relation toa physical or logical component or an oppratton 
or process implies that the behaviour Ihereof is predictable under substantially any operating condition and highly 

SS resistant to interference or subversion by external agents, such as subversive application software, viruses or physical 

[oaS ren The term -host computer 1 as ised herein refers to a date processing apparatus having at Wast one data 
processor, at least one form of data storage and some form of communications capability for in^^gwrth external 
entities such as peripheral devices, users and/or other computers locally or via the Internet. The te^Jhost computer 
ao system 1 in addition to the host computer itself includes standard external devices, such as a keyboard, mouse and 
VDU that attach to the host computer. . 
rooan The term 'document', as used herein, includes any set ol data that can be visualised using a host computer 
system. Commonly a document will be a textual document, such as a contract However, a document may comprise, 
graphics, or pictures, instead of. or as well as. text. In general, a document may comprise a single page or multiple 

35 room The term 'pixmap 1 , as used herein, is used broadly to encompass data defining either rrwnochrome or colour 
or grayscale) images. Whereas the term -bitmap 1 may be associated with a monochrome image only, for example 
Sere a single bit ? set to one or zero dependhg on whether a pixel is W or 'off. "pixmap- is a more ' 9«eral lenu 
which I encompasses both monochrome and colour images, where colour Images may require up to 24 brts or more 

40 to define the hue. saturation and intensity of a single pixel. nm ui^ „ 

[0028] As will become apparent, the trusted component accordng to the preferred «^^^ r ^P^f?^ 
secure user interface and. in particular, controls at least some of the display Ml of rts ^wtco^etTJ 
trusted component herein may or may not also acquire integrity metrics according ^^^^^J^' 
cant's co-pending patent application, although such acquisition of integrity metnes will not be ccflsideredheren, 

45 [00291 in essence, the preferred embodiment enables a user to digitally sign a (xxument stored on a r«« computer 
using the private key of the user's smartcard. or other form of secure token such as a cryptographic processor The 
signing is enacted by a trusted display processor (i.e. the trusted component) ofthe host computer 
that provide the user with a high level of confidence that the document bemg v«wed on screen « f^™" 1 
the smartcard is signing. In particular, the smartcard carries trusted image data, or a -seal . which te passed to the hart 

« computer over a secure channel and displayed by the trusted component during the signing procedure. It is m part the 
display of the trusted image, which is typically unique to the user, which provides the user wrth the confid^eth* the 
trusted component is in control of the signing operation. In addition, in the preferred embodiment, the host co^uter 
provides a trusted input device, connected directly to the trusted display process^ by which the user can interact with 
the host computer in a manner which cannot be subverted by other functione of the host computer. 

ss [0030] More particularly, the trusted d.splay processor or a device with similar properties ts a f^ a ^ ^J^* 0 
data at a stage in the video processing beyond the point where data can be manipulated by standard host computer 
software This allows the trusted display processor to display data on a display surface without interference orsubver- 
sion b y the host computer software. Thus, the trusted display processor can be certain what mage is currently being 
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displayed to the user. This is used to unambiguously identify the image (pbcmap) that a user » s^mng. Assert 
anETtM ihe trusted display processor may reliably display any of as data on the d.splay surface, .ncludng. for 
example, the integrity metres ot the prior patenl application, or user status messages « piornpte. 
Si ItwiObelppreciatedthat. Wiethe prefenedembrfin^^ 

to be able to trust his host computer system, for example during an electrons transaction. oomouler 
0032] Figure 1 Urates a host compu^ 

sTpersonal Computer, or PC. which operates under the Windows NT™ operating system. Accoiding to ^w^e 
M SSL 100 is connected to a visual display unit (VDU) 105. a keyboard " 0 .~ H 15 ^ ^2 
SenS "and a local area network (LAN) 1 25. which in turn Is connected to the Internet 1 30. Herein, the smartoard 
S ^n^epenJent unit, aKhough it may bean integral part of the keyboard. In f^J^^^*^ 
7S£ input device, in this case a trusted switch 135. whidii 8 imegrated intone keyboard JT^'^C 
mouse, and trusted swlch can be thought of as the humanAjomputer menace (HCI) ' 
Sfy the trusted switch and the display, when operating under trusted control, asw.ll bede^n^c^beth^gW 
ofas a -trusted user interface 1 . Figure 1 also illustrates a smartcard 122 lor use m the present embodiment as wiD be 

r00331 Figure 2 shows a hardware architecture of the host computer of Figure 1. _ „ 
2 Aborting to Figure 2. the host computer 100 comprises a central processing unit (CPU) 200. 
Seeded » rna* memory, which comprises RAM205andROM2lO, aBof ^^^T^^ 
215 ot ihe host computer 100. The CPU in this case is a Pentium™ processor. The CPU « connected vaarei 
Peripl^lS^lnterconnect) bridge 220 to a PCI bus 225, to whichare ^^^^^Z^ 
L the host «™pWl<X>. The bus 225 comprises appropriate control, 

described in detail herein. For a detailed description of Pentium process^ and PO a ^T^^^ 
the scope of the present description, the reader is referred to the book, The Indispensable PC Hardware ften*cok^ 
M BftbL by Hans-Peter Messrner. published by AddTson-Wesley. ISBN 0-201 -40399-4. Of course, the P™*««* 
SinS in no way limited to implementation using Pentium processors. Windows™ ^^-TT^^ 
The other main components of the host computer 100 attached to me PCI b ^f ^ nclu^a SCSM^I 
euBlom in , e(faca i -darter connected via a SCSI bus 235 to a hard disk drive 240 and a CD-ROM drive 245. 

^^LZZT. host computer, (no, shown), such as filers, print 

ti» internet 130- an IO (input/output) device 225. tor attaching the keyboard 110. mouse 115 and smartcard reader 

numbTof further taste, which will be described in detail below. 'Standard display functions' ^ ^ 
cTwould normally expeel to find in any standard hosl computer 100, for example a PC operating underthe Wbdcws 
^Lating systemX displaying an image associated with the operating system or V*****"!^^ 
b^ no^tZL keyboard 110 has a connection to the IO device 255. as well as a direct connection to the trusted 

?oS« ^e^components. m particular the trusted display processor 260. are preferably also integrated onto 
mother^rdTs ^ZZx compter ,00. although, sometimes. LAN adapters 250 and SCSI adapters 230 can 

40 £S5 he C 9 i iThows a preferred physical architecture for the trusted dtsptey prcx^^n a^c^h 
hTpreferr^^ 

of a trusted component, providing the standard display functions of a display processor and the extra. norv«U«terd 
^st^ng statures and proving a trusted user ^ ^T^H * 

as the functions could alternatively be physically split into two or more separate physical components. However, it wraoe 
a?p,S^ 

a most elegant and convenient solution. 

[0036] According to Figure 3. the trusted display processor 260 composes: 

ncTvSmer^^, for example flash memory, containing respective control program instruction, 
f"^Hor cTiTf^ operat^ ot the microcontr^.er 300 (anemat^ry. ^ tru^^^r«e^0 
could be embodied in an ASIC, which would typtealy provide greater performance and cost efficiency in mass 
production, but would generally be more expensive to develop and less flexible); 
ss In Menace 310 for connecting the trusted display processor 260 to the PCI bus for receiving ^J**** 
araohics primitives) from the CPU 200 and also trusted image data from the smartcard 122. as will be described: 
f^Ti rnerSy 31 5, ^ emprises suffice VRAM (video RAM) * wh*i to 
frame (a typical frame buffer memory 31 5 is 1 -2 Mbytes in size, for screen resolutions of 1280x768 supporting up 
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t^SciSH ^ analogue converter) 320 for converting pbcmap data into analogue signals for driving the 
(analogue) VDU 105. which connects to the video DAC 320 via a video interface 325; 
an interface 330 for receiving signals directly from the trusted switch 1 35; 
s o^e^^ 

information, particularly received cryptographic keys, and for provrimg a work area tor the nrucrocontrolrer 300. 
m££> processor 340. comprising hardware cryptographic accelerators andtor software arranged to pro- 
viSSStJddisptey processor^) wHh a cryptograph* iden«y and 

fidentialily. guard against replay attacks, make digital signatures, and use digrtal certificates, as wil be described 

10 Si for example flash memory, lor storing an identifier I „ of the trusted display processor 

, Star^TsSSe text m£ name), a private key ^ « the 

Certno signed and provided by a trusted third party certification agency, such as venSign Inc., which bnds the 
mSed 5* processor 260 with a signature public-private key pair and a confidential^ pubbc-pnvate key pair 

is and includes the corresponding public keys of the trusted display processor 260. 

f00391 A certificate typically contains such information, but not the public key of the CA. That public key is typically 
Ss^ZZZT^ Key infrastructure' (PKI). Operation of a PK. is well known to those skilled m the art of 

x ST The certificate Certep Is used to supply the public key of the trusted display processor 260 to third parties in 
sTa way that third partieTare confident of the source of the public key.end mat thepub.K 
public-private key pair. As such, it is unnecessary tor a third party to have pnor knowledge of. or to need to acqure. 

the public key ol the trusted display processor 260. _ 

MM?] Thetrusted display processor 260 lends its identity and trusted processes to the host computer and the trusted 

25 display processor has those properties by virtue of its tamper-resistance, resistance to forgery, and resmtanc* to coun- 
SI Onty setected entities with appropriate authentication mechanisms are able to mfluence the processes run- 
^Mk^dMVI^M Neitheranordinary user of the host compute, . nor any «d.nary user or 
L?oXv entity connected via a network to the host computer may access or interfere wrth the p^ses, rurmng 
inside the trusted display processor 260. The trusted display processor 260 has the property <rf baing\MoU« - 

communicate v£h the trusted display processor 260 after it is installed ontothe i"*"*^*" ^SZJto 
100. The method of writing the certificate to the trusted display processor 260 .s analogous* ' «""^"""° 
initialise smartcards by writing private keys thereto. The secure communcations is supported by a Ynaster key*, known 
on y rttTt^edlS party (and to the manufacturer of the host computer 100). that iswrrttentothetrust^dHptey 

as p^e^ 2^ during manuTacture. and used to enable the writ^g of data to the trusted d sptey processor 260. Thus, 
writino of data to the trusted display processor 260 without knowledge o) the master key is not possfcle. 
2 !Z be ^parent f romTigure 3 that the frame buffer memory 31 5 is only accessible by the trusted d.spby 
processor 260 itself, and not by the CPU 200. This is an important feature of the preferred e^jment, 6^8 It « 
imperative that the CPU 200, or. more importantly, subversive application programs or vruses, cannot modify the 

* S tr^ed operation. Of cxxireTt. would be feasibie to provde the same level «J^^»*<™ 
iZZu direct* access the frame buffer memory 315. as long as the trusted ^^^J^SSS 
to have ultimate control over when the CPU 200 could access the frame bufler memory 315. Obviously, this fatter 

scheme would be more difficult to implement. . . , lnnuuinnriw , ha desert>ad 

[0044] A typical process by which graphics primitives are generated by a host computer 100 will rww be asserted 

<5 byway of bSoSnd. InltJry, an appHcation program, which wishes to display a ^r^mage J^«"PP£ 
oriate call via a graphical API (application programming Interface), to the operating system. An API typically provides 
a^ d lrfaSTor an appZton program to access specific underlying dteplay functions, such as provided by 
wSo^ NT^, for the purposes ol displaying an image. The API call causes the operating system to make respect™ 
^driver Iterary ZSZL. which resufi n the generate of graphics ^ S ^^^ZTp^ 

so which in this case is the trusted display processor 260. These graphics primitives are finally passed by the CPU 200 
,0 me tmsts^^ processor 260. Example graphics primitives might be 'draw a line from pent x to po.ntyw.th 
thickness t or fiO an area bounded by pointew.x.y and z with a colour a'. 

S The contS program of the n^ocontro.ler 300 controls the microcontroller to provide the standard display 
functions to process the received graphics primitives, specifically: 

receMngtromthe CPU 200andprrc^ 

JZS be displayed on the VDU 105 screen, where the pixmap data generally includes -n.ensrty values 
for each of the red, green and blue dots of each addressable pixel on the VDU 105 screen; 
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storing the pixmap data into the frame buffer memory 315; and 

periodically, for example sixty times a second, reading the pixmap data from the frame buffer memory 315. con- 
verting the data into analogue signals using the video DAC and transmitting the analogue signals to the VDU 105 
to display the required image on the screen. 

[0046] Apart from the standard display functions, the control program includes a function to mix display image data 
deceived from the CPU 200 with trusted image data to form a single pixmap. The control program also manages 
interaction with the cryptographic processor and the trusted switch 1 35. 

[0047] The trusted display processor 260 forms a part of the overall 'display system 1 of the host computer 100; the 
10 other parts typically being display functions of the operating system, which can be 'called* by application programs and 
which access the standard display functions of the graphics processor, and the VDU 105. In other words, the "display 
system' of a host computer 1 00 comprises every piece of hardware or functionality which is concerned with displaying 
an image. 

[0048] As already mentioned, the present embodiment relies on interaction between the trusted display processor 
'£ 260 and the user's smartcard 122. The processing engine of a smartcard suitable for use in accordance with the 
preferred embodiment is illustrated in Figure 4. The processing engine comprises a processor 400 for enacting standard 
encryption and decryption functions, to support digital signing of data and verification of signatures received from 
elsewhere. In the present embodiment, the processor 400 is an 8-bft microcontroller, which has a built-in operating 
system and is arranged to communicate with the outside world via asynchronous protocols specified through ISO 
20 7816-3, 4, T=0, T=1 and T=14 standards. The smartcard also comprises non-volatile memory 420, for example flash 
memory, containing an tdentiier \qq of the smartcard 122, a private key $qq, used for digitally signing data, and a 
certificate Certsc. provided by a trusted third party certification agency, which binds the smartcard with public-private 
key pairs and includes the corresponding public keys ot the smartcard 1 22 (the same in nature to the certificate Cerfep 
of the trusted display processor 260). Further, the smartcard contains 'soar data SEAL in the non-volatile memory 420, 
. 2S which can be represented graphically by the trusted display processor 260 to indicato to the user that a process is 
operating securely with the user's smartcard, as will be described in detail below In the present embodiment, the seal 
data SEAL is in the form of an image pixmap, which was originally selected by the user as a unique identifier, for 
example an image of the user himself, and loaded into the smartcard 122 using well-known techniques. The processor 
400 also has access to volatile memory 430, for example RAM, for storing state information (such as received keys) 
30 and providing a working area for the processor 400, and an interface 440, for example electrical contacts, for commu- 
nicating with a smart card reader. 

[0049] Seal images can consume relatively large amounts of memory If stored as pixmaps. This may be a distinct 
disadvantage in circumstances where the image needs to be stored on a smartcard 1 22, where memory capacity is 
relatively limited. The memory requirement may be reduced by a number of different techniques. For example, the seal 

3S image could comprise: a compressed image, which can be decompressed by the trusted display processor 260; a 
thumb-nail image that forms the primitive element of a repeating mosaic generated by the trusted display processor 
260; a naturally compressed image, such as a set of alphanumeric characters, which can be displayed by the trusted 
display processor 260 as a single large image, or used as a thumb-nail image as above. In any of these alternatives, 
the seal data itself may be in encrypted form and require the trusted display processor 260 to decrypt the data before 

40 it can be displayed. Alternatively, the seal data may be an encrypted index, which identifies one of a number of possible 
images stored by the host computer 1 00 or a network server. In this case, the index would be fetched by the trusted 
display processor 260 across a secure channel and decrypted in order to retrieve and display the correct image. Further, 
the seal data could comprise instructions (for example PostScript™ instructions) that could be interpreted by an ap- 
propriately programmed trusted display processor 260 to generate an image. 

4$ [0050] Figure 5 shows the logical relationship between the functions of the host computer 100, the trusted display 
processor 260 and the smartcard 122, in the context of enacting a trusted signing operation. Apart from logical sepa- 
ration into host computer 100, trusted display processor 260 or smartcard 122 functions, the functions are represented 
independently of the physical architecture, in order to provide a clear representation of the processes which take part 
in a trusted signing operation. In addition, the 'standard display functions' are partitioned from the trusted functions by 

so a line x-y, where functions to the left of the line are specifically trusted functions. In the diagram, functions are repre- 
sented in ovals, and the 'permanent 1 data (including the document image for the duration of the signing process), on 
which the functions act, are shown in boxes. Dynamic data, such as state data or received cryptographic keys are not 
illustrated, purely for reasons of clarity. Arrows between ovals and between ovals and boxes represent respective 
logical communications paths. 

bb [0051] In accordance with Figure 5, the host computer 100 includes: an application process 500, for example a 
wordprocessor process, which requests the signing of a document; document data 505; an operating system process 
510; an API 511 process lor receiving display calls from the application process 500; a keyboard process 513 for 
providing input from the keyboard 110 to the application process 500; a mouse process 514 for providing input from 
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the mouse 1 1 5 to the application process 500; and a graphics primitives process 51 5 for generating graphics primitives 
on the basis ol calls received from the application process via the API 511 process. The API process 511 . the keyboard 
process 51 3. the mouse process 51 4 and the graphics primitives process 515 are build on top of the operatng system 
process 510 and communicate with the application process via the operating system process 510. 

5 [0052] The remaining functions of the host computer 100 are those provided by the trusted display processor 260. 
These functions are: a control process 520 for coordinating all the operations of the trusted display processor 260, 
and for recervhg graphics primitives from the graphics primitives process and signature requests from the application 
process 500 a summary process 522 for generating a signed summary representative of a document signing procedure 
in response to a request from the control process 520; a signature request process 523 for acquiring a digital signature 

to of the pixmap from the smartcard 122; a seal process 524 for retrieving seal data 540 from the smartcard 122; a 
smartcard process 525 for interacting with the smartcard 122 in order to enact challenge/response and data signing 
tasks required by the summary process 522, the signature request process 523 and the seal process 524; a read 
pixmap process 526 for reading stored pixmap data 531 and passing it to the signature request process 523 when 
requested to do so by the signature request process 523; a generate pbtmap process 527 for generating the pixmap 

is data 531 on the basis of graphics primitives and seal image data received from the control process 520; a screen 
refresh process 528 for reading the pixmap data, converting it into analogue signals and transmitting the signals to the 
VDU 105; and a trusted switch process 529 for monitoring whether the trusted switch 1 35 has been activated by the 
user. The smartcard process 525 has access to the trusted display processors identity data fc P , private key $&> data 
and certificate Certop data 530. In practice, the smart card and the trusted display processor interact with one another 

20 via standard operating system calls. . 
[0053] The smartcard 1 22 has: seal data 540; a display processor process 542 for interacting with the trusted display 
processor 260 to enact challenge/response and data signing tasks; smartcard identity data lso smartcard private key 
data Sec and smartcard certificate data Certsc 543. ■ . 

[0054] A preferred process for signing a document using the arrangement shown in Figures 1 to 5 wui now be de- 

25 scribed with reforenco to the flow diagram in Figure 6. _ 
[0055] Initially, in step 600.'the user controls the application process 500 to initiate a 'signature request for digitally 
signing a document. The application process 500 may be realised as a dedicated software program or may be an 
addition for example a macro, to a standard word processing package such as Microsoft's Word. In either case, neither 
the signature request nor the application process 500 need to be secure. When the user initiates the signature request. 

30 he also specifies the document to be signed, if it is not one which is already filling the whole screen. For example, the 
document may be displayed across a part of the full screen area or m a particular window Selection of a particular 
area on screen is a simple task, which may be achieved in several ways (using a WIMP environment), for example by 
drawing a user-defined box bounding the area or by simply specifying co-ordinates. 

[0056] Next, in step 602, the application process 500 calls the control process 520 to sign the image that is being 

3S displayed (within a defined area or window) on the screen; the control process 520 receives the call. In parallel, although 
it is not shown, the control process 520 receives any graphics primitives from the graphics primitives process and 
forwards them onto the generate pixmap process 527. The call from the application process 500 to sign a document 
includes the co-ordinates (a f b,c,d) of the edges of the document. Note that this sending of coordnates generaly 
enables the signing of the entire surface of the screen, a complete window or of an arbitrary part of the screen. The 

40 application process 500 then waits for the control process 520 to return the signature of the image. 

[0057] In response to the signature request, in step 604, the control process 520 forces the image that is to be signed 
to be 'static 1 from the time of the request until the process has been completed. Herein, 'static' means that the document 
image cannot be modified other than by the trusted display processor 260. This is so that the user can be certain that 
what he sees is what he is signing at all times during the process. In the present embodiment, the control process 520 

as achieves a 'static' display by 'holding-otl. or not processing, any further graphics primitives. In some situations, the 
graphics primitives process (or equivalent) may •buffer' graphics primitives until the control process 520 Is ready to 
receive further graphics primitives. In other situations, graphics primitives tor the image to be signed may simply be 
lost. Where the document image fills the whole screen, making the image sialic is simply a case not processing any 
graphics primitives. However : where the image to be signed forms only a subset, for example a window, of the full 

so screen, the control process 520 needs to determine whether received graphics primitives would aff ect the 'static' area, 
and reject ones that would. As such, the pixmap of the static document mage in the frame buffer memory 31 5 remains 
unchanged by any instructions from the graphics primitives process, or any other process executing on the CPU 200. 
while the document image is static. 

[0056] Once the document image has been made static, in step 606, the control process 520 instructs the generate 
55 pbcmap process 527. including in the call the coordinates (a,b.c,d) provided by the application process 500, to modify 
the pixmap to highlight the document to be signed, as will be described in more detail below with reference to Figure 
10c. Then, in step 608. if a smartcard 122 is not already inserted in the smartcard 122 reader 120. as determined by 
the smart card process 525, the control process 520 instructs the generate pixmap process to display a graphical 
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message asking the user to insert his smartcard 122. This message is accompanied by a ten second countdown timer 
COUNT. If the countdown timer expires (i.e. reaches zero), as a resul of not receiving the smartcard 1 22. the control 
process cancels the signing'operatbn in step 614 and returns an exception signal to the application process 500. In 
response, the application process 500 displays an appropriate user message in step 616. If the smartcard 122 is. 

5 inserted in time, or is already present then the process continues. 

[0059] Next, in step 618, the control process 520 calls the seal process 524. and the seal process 524 calls the 
smartcard process 525, to recover the seal data 540 from the smartcard 1 22. Optionally, the control process 520 cals 
the generate pfocmap process 527 to display another message indicating to the user that recovery of the seal data 540 
is being attempted. In steps 618 and 620, the smartcard process 525 of the trusted display processor 260 and the 

io display processor process 542 of the smartcard 122 interact using well known, ■chaHengeAesponse' techniques to 
enact mutual authentication and pass the seal data 540 from the smartcard and back to the control process 520. The 
details of the mutual authentication process and passing of the seal data 540 will now be described with reference to 
Figure 7. 

[0060] According to Figure 7, the smartcard process 525 sends a request REQ1 to the smartcard 1 22 to return the 
1$ seal data SEAL 540. The display processor process 542 generates a nonce R, and sends it in a challenge to the 
smartcard process 525. The smartcard process 525 generates a nonce and concatenates ft with nonce R|, signs 
the concatenation Ft, IIRj with its private key to produce a signature sS^ft,!^), and returns the concatenation R 1 HR 2 i 
the signature sS^R, IIFfe) and the certificate Cer^p back to the display processor process 542 of the smartcard 1 22. 
The display processor process 542 extracts the public key of the trusted display processor 260 from the certificate 
zo Cert DP , and uses this to authenticate the nonce R, and the signature sS DP (R 1 llr\) by comparison with the concate- 
nation R, I IR 2 , lo prove that the seal request came from the expected trusted display processor 260 and that the trusted 
display processor 260 is online. 

[0061] The nonces are used to protect the user from deception caused by replay of old but genuine signatures {called 
a 'replay attack') by untrustworthy processes. 

25 [0062] Tho display processor process 542 of the smartcard 122 then concatenates Rg with is seal data SEAL 540, 
signs the concatenation RgllSEAL using its private key Sec to produce a signature sS sc (R 2 IIS£AL) l encrypts the seal 
data SEAL 540 using its private key Ssc to produce encrypted seal data 540 sS sc (SEAL), and sends nonce R2, the 
encrypted seal data sS^SE AL), the signature sS^FyiSE AL) and the smartcarefs certificate Certsc to the smartcard 
process 525 of the trusted display processor 260. The smartcard process 525 extracts the smartcarefs public key from 

do the certificate Certsc and 11868 tnis to verifv nonce *2 and the signature sS 3C (R 2 IISE AL). decrypt the seal data SEAL 
540 from the encrypted seal data 540 s$sc(SEAL) and, finally, return the seal data SEAL 540. via the seal process 
524, to the control process 520. 

[0069] Returning to Figure 6, in step 622, when the control process 520 receives the seal data SEAL 540, rt forwards 
the data to the generate pixmap process 527, and instructs the generate pixmap process 527 to generate a seal image 

35 and use it to highlight the document to be signed, as will be described below with reference to Figure lOd. Then, in 
step 624, the control process 520 instructs the generate pixmap process 527 to display a message to the user asking 
whether they wish to continue with the signing operation. This message is accompanied by a ten second countdown 
timer COUNT. If the countdown timer expires, in step 626, as a resul of not receiving a response from the user, the 
control process cancels the signing operation, in step 628, and returns an exception signal to the application process 

40 500. In response, the application process 500 displays an appropriate user message in step 629. If, in step 630, the 
user responds positively by actuating the trusted switch 1 35 within the ten second time limit, the process continues. 
The authorisation to continue could alternatively be supplied over an unreliable channel, rather than by using a trusted 
switch 135, or even using appropriate software routines, providing a reasonable level of authentication is used. Alter- 
natively, it may be decided that the mere presence of an authentic smartcard may be sufficient authorisation for the 

«s signing to occur. Such an alternatives are a matter of security policy. 

[0064] Next, in step 632, the control process 520 instructs the signature request process 523 to request the signing 
of the document image; the signature request process 523 calls the read pixmap process 526 to request return of a 
digest of the pixmap data of the document to be signed; and the read pixmap process 526 reads the respective pixmap 
data, uses a hash algorithm to generate a digest D PfX of the pixmap data and returns the digest to the signature request 

so process 523. Additionally, the read pixmap process 526 generates 'display format data 1 FD, which includes information 
necessary to reconstruct the image from the pixmap data into a text-cased document at a later time (FD is not essential, 
since the document text may not need to be reconstructed), and returns this also to the signature request process 523. 
For example, the display format data FO may include the number of pixels on the screen surface and their distribution, 
such as '1024 by 768', and the font type and size used for the text (if the document is text-based) in the document (at 

ss least some of this information may instead, or in addition, be contained in a document 'summary 1 , as will be described 
below). In steps 634 and 636, the signature request process 523 interacts with the display processor process S42 of 
the smartcard 122 using well-known challenge/response processes to generate an individual signature erf the docu- 
ment, as will now be described in detail with reference to the flow diagram in Figure 8. 
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[0065] Accordin 9 toFigure8.thesro^ 

a signature ol the digest 0 PIX and display format data FD. The display processor process 542 of the 

tSZS* general a Sm Rs and send** it to the smartcard process 525 with a challenge to ^return the d^ 

Dp^and the display foimat data FD. The smartcard process 525 concatenates the digest Dprx with the JgJ^J"J 

s Jte FD and nonce R 3 . and signs the concatenation 0 P1X IIFDIIR3 to produce a signature ^OP<Dp«IIFDNR^. The 
smartcard process 525 then sends the concatenation Dp K IIFDIIR3 and its respective signature ^W*"f£ * 
the display processor process 542 of the smartcard 122. The display processor process 542 uses the trusted display 
processes public key (which It has already received in the seal data 540 exchange) to verify the trusted dnptay 
processor's signature sSopPpocllFDIIRa) and nonce Rj, to prove that the digest is the current image dtgest The display 

•o pZTsZ, process 54 2 ligns *e diges? of the pbcmap P P1X and the display format data FD. using *s private toy. to 
produce two signatures sS^D^) and sSsc(FD) respectively. The display processor process 542 of the smarKard 
M. returns thTsTgned digS and signed display format data sS^FD) to the smartcard proceed 

the trusted display processor 260. The smartcard process 525 next verifies the digest Dp, x and display «c<rnat data 
FD, using the anartcard's public key (which it already has as a result of the seal data 540 exchange), and verifies the 

is smartcard's signature, to prove that the smartcard is still onfne. 
[0066] Retu^gtoFio^re6.ins.ep638.thesrr B ^^ 

nates the pbcmap PIX, the smartcard's signed versions of the pixmap digest sS^D^) and deptey »«ma < dM^o 
(FD) to form an individual signature PIXIIsSsctD^llsSacfFDXrt the image, and returns tl. vteHthe skjnature i^usst 
process 523. io the control process 520, which returns the individual signature to the application processSOO. The 
» applfcalton process 500 stores the individual signature, in step 640. and responds with a further call to the control 
plocess 520 to 'summarise the signing' operation in step 642. The purpose of a summary is to completethe signature, 
as will be described with reference to the flow diagram in Figure 9 and also the example summary below. 

IS 1 TC-88503-00.01 

2 Access time: Thu 06-May-1999, lit IB 

3 Pages: 2 

4 ImageOl I 560 x 414 (187,190) (1024 x 168) 

^r4™0LcWtwr U PdskyI.4uk3no0w 
cY5rTC563klov0PTBI 11 yqZPxRnic- 

7 END SIGNATURE 

8 Image02 | 670 x 379 (201,228) (1024 x 768) 
35 10 Wlw5Rgr5F0iAj!w4GM 



<0 7 2Z v+4fFttuSgOZI4n5iBkSEwtEj026ilc/np6paq+01GQZhhJCbq8OaX97Gindg3AoBq4x*D 
hu jmqkCJO+Dz6+x8lcE24 Z8YFXLPOI- 

11 END SIGNATURE 

12 Summary signature: 

ktaTdTqY/gPhlGajrSJGqRms+we/c- 
15 END SIGNATURE 

50 [00671 In step 644, the control process 520 calls the summary process 522 to generate a summary message SUM 
containing the number of images (two in the example summary above) plus the Individual signatures^ the images 
(lines 6 and 10 of the example), a label identifying the trusted display device (line 1 in the example), the current time 
and date (line 2 in the example) and a signed digest of the summary itself (line 14 in the example). For each image. 

ss the summary also includes the size of the image in pixels (e.g. 560x414 for image 1). the offset from the origin of the 
screen in pixels (e.g. 187.190 for image 1) and Ihe display resolution in pixels (e.g. 1024x768 for image 1). 
[0068] The summary process 522 then generates a digest of the summary Dsu M In step 646 and calls the smartcard 
process 525 of the trusted display processor 260 to interact with the srrartcardl 22 usirigc*allerige*espcflse process 
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to generate a signature of the summary digest D^. as will now be c^ribed^h reference ******* 
00891 AecordingtoFigur*9,1hesrriart^ . 
Srtureofthe digest of thesumrnaryDsuM.Thedisplay processor process 542dthes™ 
r! and sends it in a challenge to return the digest of the summary Dsum- The smartcard P-ocess525 cor^enates 
the digest D SUM with nonce R, and signs the concatenation ^IIR, to produce a signature ^(D^'^The 
smartcard process 525 of the trusted display processor 260 then sends the concatenation D SUM IIR 4 and respectrve 
sionature sLp(D« M HR4) to the display processor process 542. The display processor process 542 then verifies the 
rSwSl signature3nonce R,. using the trusted dfepby processor's public key (which it already 
has from the seal data 540 exchange), to prove that the summary is the current summary Ne* thedsptay processor 
process 542 signs the digest of Hie summary D SUM using its private key and sends the signed digest ^sc^scw)^ 
the smartcard process 525. The smartcard process 525 of the trusted display processor 260 verifies the digest and 
verifies the smartcarcfs signature, using the smartcartfs public key. to prove that the smartcard is still ontae. 
roOTOl Returning to Figure 6. in step 652. the smartcard process 525 returns the summary SUM concatenated with 
Seined digest of the summary sS^CD^) (to form ^^^^^l^^ZL^ 
522. to the control process 520, and the control process 520 returns the summary SUMIlsS sc (D SUM ) to the application 

process 500. The application process 500 receives the summary in step 654. 

Foo7il The individual signature and summary may be used by the application process 500. or anyother process 
running on the host computer 100 n various ways outside the scope of this invention, including as proof of contract, 
for storage or for transmission to other entities. ... w „_„ cil ,„ 

20 mam Finally, h step 656. the control process 520 unfreezes the display, by recornrnenang receipt and processing 
of graphic primitives associated with the document image, and thereby in effect returns ^^^f 
the application process 500 or other application software. Alternatively, control may not be handed back to the appli- 
cation process 500 until the useractuates the trusted switch 1 35 again, typically in response to another user message, 
which, ttiis time, would not have a timeout period. This would give the user more time to review the static document 
as imaoo before reluming the host computer to standard, non-trusted operation. . 

100731 In order to verify a signed document, both the individual signature PIXIIs^DpkJIIsSscKFD) and the sum- 
mary SUMIlsS-tDsHu) must be verified. Such verification methods are weD known to those skiDed in the art of soajrrty 
Elr exa^le. me si^lure on the digest of the pixmap sS^D,,*) is verified usir^ me pubiic key of the userjh«h 
is publicly available and preferably contained within a digital certificate Cert^ supplied by a certrrteatwn autr^tyThe 
30 verified digest is then compared with a value obtained by recomputing the digest from the pixmap. where the digest is 
generated using a standard, well-known and defined hash function. If the match is exact, the signature has been 
verified Other signatures, inducing the summary, are checked in the same way. 

100741 ' A preferred method of enablhg a person to verify the wording of the signed document b totranstate the 
Pixmap back into an image. This requires an application, or indeed a trusted display processor 260. to load the prxmap 
as dataPIXintotheframebufferrr*™^ 

SoTOl 6 ^s^S^lightirKjaoVKurnent to be signed will now be described with reference to Figures 10a to 10d. 
■00761 In the preferred embedment, the seal data SEAL comprises a pixmap of a trusted image. For example, as 
shown in Fiaure 10a the pixmap of the seal data 540 defines a -smiley face' 1000. Figure 10b illustrates an image 

40 i005o» an exempted documentDocI to be signed, in a window 1010 of the screen (notshown). As a first highlightng 
su» atte?S image has been made static but before the seal data has been received, the trusted display processor 
hSS! the document to be signed by superinposrg a frame 1020 around the document .mage 1005. as illus- 
trated in Figure 10c. Also, where a smartcard 122 is not present, a user message 1030 asking the user to insert his 
smartcard fe displayed accompanied by a ten second countdown timer 1035. as also illustrated in Figure 10c Next, 

4S when the smiley face pixmap image is retrieved from the smartcard 1 22, the trusted dteplay P^^^/ a "^"f 
the frame 1040 with multiple instances 1045. or a mosaic, of the smiley lace, as shown in Figure 10d. In addrticn.as 
shown in Figure lOd, the trusted display processor 260 generates a further user message 1050. accanpanied by a 
ten second countdown timer 1055. asking the user whether they wish to proceed wlh the signing process. This em- 
bellished frame 1040 both indicates to the user that the correct static image area is being acted on and provides the 

so user with a high level of confidence that the trusted display processor 260 is fully in control of the sigmng process; the 
Dresence of the user's own seal image provides confidence to the user that the message has come from the trusted 
display processor 260 rather than from some other (possibly subversive) software application or hardware device. 
roOTTl Figures 10e and 10g illustrate alternatives to the frame' visual effect illustrated in Figures 10c and lOd. In 
Fiaure 10s four single seal images 1060 are positioned at the comers of the static document image using the co- 

55 ordinate* provided by the application process 500. to define the sialic image area. In Figure 1 0f. the static rmage ts 
defined by modifying the background thereof to show a single seal image. In Figure 10g. the static mage »s defined 
bv modifying the background thereof to show a mosaic of seal images. It is expected that the skilled reader will be able 
to think of other visual effects by which the static image may be highlighted in the light of the present description. In 
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addition, it may be desirable to include further status messages during the signing operation, for example 'Retrieving 
seal data 540 now....". 'Generating document signature now...", etc. 

[00781 It will be appreciated that the trusted display processor 260 needs to be able to display the seal image(s) and 
the messages in the correct places on screen. Clearly, the seal image and the message images are temporary, to the 

s extent they appear during the signature process and disappear thereafter There are well-known, standard display 
techniques lor overlaying a first image with a second image, thereby obscuring a part of the first image, then removing 
the second image and restoring the portion of the first image that had been obscured. Such techniques are used as a 
matter of course in normal windows environments, for example, where multiple windows may overlap one another. 
The trusted display processor260 is arranged to implement one of more of these standard techniques for the purposes 

io of superimposing the seal image(s) and the message images over the standard display. 

[00791 In some scenarios, it may be that a document is too large to fit all at once onto the VDU 105 screen and slill 
be easily read by a person. Obviously, for the present embodiment to be practical, it is essential that a user can very 
clearly read the document before signing it. Therefore, the document can be split into multiple screen pages, each of 
which needs to be signed and cryptographicaliy chained to the signature of the previous page, as will now be described. 

is [0080] First the application process 500 causes the image of the first page to be displayed and makes a call to the 
trusted display processor 260 for signing as b el ore. When the trusted display processor 260 returns the "dividual 
signature, instead of requesthg a summary, the application process 500 instructs the trusted display processors^) 
to display the Image of the second page and sign the image. Clearly, in this case, the trusted display processor 260 is 
arranged to support such a request by the application process 500. Only after all Images have been signed and returned 

20 to the applfcaiion process 500 does the application process 500 issue a request for a summary. Then, the summary 
includes the number of images that were signed in this multi-page document, for example as illustrated in the two- 
page summary above. u . . . . 
[0081] The first page in the multi-page document is signed in the same way as a single page, resulting m return of 
an individual signature. When subsequent images are presented for signng, however, the trusted display processor 

as 260 recognises that thoy are part of a multi-page document because no summary request was received after the 
previous signature request As a result, the trusted display processor 260 displays a different message, which requests 
permission from the user to sign a continuation page. In response, the user who is signing a multi-page document uses 
the same reliable permission channel as before (lor example, the trusted switch 1 35) to confirm to the trusted display 
processor 260 that this page is associated with the previous page, and is also to be signed. When the trusted display 

so processor 260 receives this multi-page confirmation, it concatenates the signature of the previous signed page with 
the pixmap of the current page, creates a digest of the concatenation, and sends thai to the smartcard for signing. This 
is instead of sending a digest of just the current pixmap. This process cryptographicaliy 'chains' a subsequent page to 
the previous page, so that pages cannot be rearranged without detection, nor can intermediate pages be inserted or 
deleted without detection. ' k 

ss [0082] The validity ol the first page may be checked in exactly the same way as a single page. The validity of sub- 
sequent pages is checked using the same method as for a single page, except that the digest of the current pixmap 
is replaced by the digest of the concatenated previous signature and current pixmap. 

[0083] It will be appreciated that there are many ways of cryptographicaliy chaining a subsequent page to a previous 
page Such ways will be obvious to those skilled in the art of security in the light of the present description. 
40 [00841 For added security, the image of each page of a multi-page document may be arranged to include the con- 
ventional footer 'Page x of y. where V is the number of the page and y is the total number of pages. This enables 
ready detection by a person ot a truncated document simply by reading the document. 

[0085] A significant benefit of the present document signing scheme is that a signed document can be re-signed and 
countersigned As such, it is preferable lor the summary of a document to include an audit trail. There are many vart- 

« auons on re-signing and countersigning, although (obviously) an electronic integrity check should always be done 
before any further signing. At one extreme, the new signer could view, confirm and re-sign each signed Image in turn, 
effectively replacing the original signature by a new one. This method could be used, for example, by a user signing 
a document prepared tor him by someone else. At the other extreme, the new signer could simply 'rubber stamp the 
original signature by signing the original summary, without necessarily viewing the document at all. This could be useful 

so to a manager countersigning the work of a trusted employee. 

[0086] For a re-signng operation, the application process 500 issues a re-signing request, and transmits an already 
signed document (plus the individual signature^) and the summary) to the trusted display processor 260. The trusted 
display processor 260 verifies the signed document using the pubic key of the signer, recovers the pixmap of the 
document (or each page of the document) and displays each verified image in the correct order to the new user, as if 

ss they were original images trom the signature request application. The user confirms the acceptance of each individual 
image for example using a trusted switch 1 35 as before, and causes the images to be signed as before by a smartcard 
belonging to the new user. This results in a signed document that is the same as the original document, except that it 
has been signed by the smartcard belonging to the new user. 
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[0087] Similarly, for a counter-signing operation, the application process 500 issues a counter-signing request and 
transmits the signed document (plus individual signatures and the summary) to the trusted display processor 260The, 
trusted display processor 260 verifies the signed document and displays each verified image in the correct order to 
the new user, as i they were original images from the application process 500. The user confirms acceptance oteach 
s individual image and the trusted display processor 260 signs the original summary using the smartcard belonging to 
the new user. Optionally the new user could provide a certificate of the previous user's public key. signed by the new 
user, to ease the processing overhead associated with later verification of the signature. 

[0088] Clearly, there are many possible variations on the theme of re-signing and countersigning, which win be ap- 
parent to the skilled person in the fight of the present description. u . ! , 

vo [0088] Since a document may have a history of signing, re-signing and/or counter-signng. me present emba 

conveniently provides audit information, which forms part of the document summary. This audit information allows the 
signature history of the document to be traced. The audit information includes data about the previous state of the 
document and the actions taken by the new user to create the new state of the document. The audit Wonnaton » 
signed by the trusted display processor 260, since the audit information must be independent of the user. The audit 

,5 information always contains any previous summary information (including the signature on that summary information, 
by the previous signer). If the signed document has been created from scratch, the identity label bp of the trusted 
display processor 260 is inserted as an audit root. The audit information preferably ateo includes an indication of which 
individual images were viewed and confirmed by the new user, and whether the document was created from scratch, 
or was re-signed, or was countersigned by the new user. To create a summary Including audit wfomwtioathesmartcard 

to is sent a digest of the audi! information concatenated with the previously described contents of a summary, ratnerthan 
a digest of just the previously described contents of a summary. The rest of the process is as previously tiesatoea. 
[00901 An enhancement to the process tor signing a document is that, prior to signing the pixmap data, ine trusted 
display prccessor 260 compresses the pixmap using a lossless compression algorithm so that the overheads associ- 
ated with storing and sending the individual signature are reduced. 

2s [0091] The pixmap may be compressed by standard compression algorithms, for example a codeword-based algo- 
rithm applying LZ-1 or LZ-2 compression. Alternatively, a technique similar to OCR (optical character recognition) may 
be used to compress the pixmap. In this case, the situation differs from conventional OCR in that the input (lata has 
been perfectly ■scanned', abaft at a lower resolution than in conventional OCR The OCR-compressed version of the 
pixmap may be generated by -blob-matching' to create an alphabet for the pixmap. constructing a pixmap of each 

30 character in the alphabet, and constructing a message using those characters, such that the message represents the 
original pixmap. This means that the pixmap can been compressed to a new alphabet and a message wnttenwthat 
alphabet Since there are, obviously, no errors nor ambiguity in the pixmap data, this is a lossless compression method. 
[00921 Another way of reducing the size of the image pixmap is by representing the image as a pure black and white 
image requiring only a single bit - set to zero or one - to define whether a pixel is black or white. Othejrwtee. the 

as document image is represented as a full colour image, where each pixel may typically require up to 24-btts. Obviously 
this technique may be suitable for sinple. black and white text-based documents. However, it would not be appropriate 

for colour documents or images. . . 

[0093] At any time, the document image may be converted back into a text-based document using an OCR-type 
process to reconstruct a standard digital textual representation of the document This technique cannot be used in the 

40 signature, since the textual mapping may be incorrect, but can be used by the receiver of a sigr^cxxumenttocaiv^ 
it back into a standard digital textual representation (such as ASCII) for subsequent machine manipulation. In preferred 
emrxxlimente. me trusted display pra»^ ■ 
[0094] To enact OCR, an OCR alphabet is generated in a standard fashion and is then matched to stored fonts and 
hence converted to a standard character set. As in conventional OCR, ambiguous matches may be retained as a 

46 pbcmap and flagged for conversion by the user. (This is unlikely, particularly « font type and size information has been 
supplied in the display format data FD, because there is no error in the data.) In cases of extreme caution, the entire 
reconstructed document should be manually checked by a person against the view of the document that the signer 
intended to sign. 

[0095] Preferably all document reconstiuction processes are done by processes that are trusted. 

so [00961 The preferred embodiment descr.bed above relies on the premise that the trusted display processor 260 has 
direct and exclusive access to video data stored in the frame buffer memory 315. beyond the point where the video 
data can be manipulated by host computer 100 software, including the operating system. This impl.es that the video 
data cannot be modified unless the trusted display processor 260 makes the modification. 
[0097] It will be appreciated that not all computer architectures are arranged in this way. For example, some computer 

ss architectures are arranged such that the frame buffer memory forms a part of the main memory, thus formiig a single 
address space (SAS) display system. One benefit of such a system is that both the CPU and the display processor 
can access the frame buffer memory and share the graphics operation overhead, thereby improving graphics perform- 
ance Clearly, an implementation of the present invention in such a SAS system cannot rely on the premise that the 
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buffer memory is safe during signing, since the CPU can still access the memory However, there are many ways in 
which such a SAS system may be modified to support implementations of the present invention. For example, the 
memory could be provided with a control line from a trusted display processor such that during a signing operation, 
the memory is prevented from being updated by data from the CPU. The memory devices themselves are Preferably 
s modified so that they include the extra logic to perform this function. Altematively. access to memory flecked by 
other loqic circuits inserted into the normal control path of the memory. Such systems, therefore, rely on the modified 
premise that the vioeo data in the fraine bii^ 

with the permission of the trusted display processor. Clearly, this premise is as valid for secure operation as the first 
premise, as long as the system is truly secure. 

io [00981 In other architectures, for example in simple graphics environments, the functionality of a dwsplay processor 
may lorm part of the operating system itsetl. thereby removing the requirement for separate display processor hardware. 
Clearly in this case, the graphics overhead put on the CPU will be higher than in a system with separate display 
processor hardware, thereby limiting the graphics performance of the platform. Clearly, there is then no place for a 
•trusted display processor 1 as such. However, it will be apparent to the skilled person that the same function as provided 

is by the trusted display processor, that of protecting the frame buffer memory and interacting with a smartcard. can be 
implemented using an appropriate trusted component, which controls the display system (in whatever form) during 

mam In other embodiments of the invention. In addition or altemattvety. the trusted display processor (or equivalent) 
includes an interface tor driving a trusted display. The trusted display might be. for example, an LCD panel display. In 

x lne same way that the trusted switch provides a trusted means lor a user to interact wilh the trusted display processor, 
the trusted display can provide a trusted means for feeding back information to the user other than via the standard 
VDU For example, the trusted display might be used to provide user status messages, as described above, relating 
to a signing operation. As such, applications running on the standard host computer should not be able to access the 
trusted display, because the display is connected either directly to the trusted display processor or via some form of 

2S trusted channel. In essence, such a trusted display is an addition to the so-called trusted interface' described above. 
In practice, there is no reason why other forms of trusted feedback device, of which the trusted display is one example, 
could not be included in addition, or as an alternative. For example, there may be scenarios where some form of trusted 
sound device would be useful for providing audble feedback. 

[0100] An alternative application for the invention is to provide a trusled inlerface during an electrone transaction. 

» in one exemplary embodiment, the user wishes to send sensitive data to a remote computer system. The user cannot 
be sure that the remote computer system, or indeed the host computer he is using, is trustworthy. In order to ensure 
that the sensitive data is safe from interception by unauthorised parties during transmission to Hie remote computer 
system, and to ensure that only the authentic remote computer system can read the sensitive data when it is received, 
the user wishes to encrypt the data using the authentic remote computer system's public cryptographic key. Injne 

as embodiment, the host computer incorporates a trusted component which interacts with the user's smart card in order 
to recover and display a trusted image as described in detail above. The trusted image may be displayed on the 
standard VDU screen or on a separate display, such as an LCD display, in order to indicate to the user that the trusted 
component, rather than a subversive application, is in control. The trusted component then interacts with the remote 
computer system in order to recover and authenticate the remote computer system's certificate contaning a respective 

*o public k ey. with the public key. the trusted component encrypts the sensitive data, which might itself also be read from 
the smartcard, and transmits the encrypted data to the remote computer system. 

[0101] There are many other applications, especially e-commerce applications, where the concept of a trusted user 
interface, providing trusted user feedback and trusted user input devests), would be valuable. As such, the present 
invention should not be read as being limited to the few embodiments described above, and should only be hmrted by 
<s the language of the claims. 



Claims 



so 1. A data processing system capable of operating in a trusted operating mode, the data processing system compris- 
ing: 

main processing means for executing at least one application process; 

a trusted component comprising means for executing a trusted process in a trust9d operating mode and means 

£5 for generating user feedback signals; 

at least one user feedback device; and _ 
user feedback processing means for receiving said user feedback signals and controlling the user feedback 
device on the basis of the signals, 
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wherein the trusted component comprises means lor controlling the user feedback processing 
the user feedback device to provide an indication thai the- data processing system is operating m a trusted 
operating mode. 

2 A data processing system accordhg to claim 1 . further comprising secure user input m ^ s - '"f™™^" 
with to exponent vfc a secure communications path, by which a user may securely interact wrth the 

trusted process. 

3. A data processing system according to daim 1 or claim 2, wherein: 

the main processing means includes means to execute at least <)ne8ppltotion process and generate signals 
characterising a main image to be displayed; _ 
the user feedback processing means comprises display processing means tor recerv,ng sari senate and gen- 
erating respective display signals for driving a visual display unit to display the man image; and 
the l^ted^nponen. comprises means to acquire and/or generate trusted mage ^™ d "^?™™ 
me display processing means to combine a respective trusted image with at least a portion of the man ".age 
in order to indicate to a user that the data processing system is operating in the trusted operating mode. 

A data processing system accordhg to darn 3. further comprising a secure token reader for resding data 1lr«n 
anSc, wnMla to a removable secure token, and a removable token confining data characlensmg the trusted 
image, wherein the trusted component comprises means to receive said data Irom the secure token. 

A data processing system according to daim 3 or daim 4. wherein the trusted component and the secure token 
each comprise means to interact with the other in order to execute the trusted process. 

A data processing system according to claim S, wherein the trusted component comprises means tooontrol the 
display processing means to combine the trusted image with the main mage to h.ghhght at least a portion of the 
mam image as being associated with execution of the trusted process. 

30 7 A data processing system according to cfeim 6. wherein the trusled component comprises means to prevent mcd- 
^oTthedisplaypro^^ 

the data processing system is executing the trusted process. 

a. A data orocessinq system according to any one of claims 5 to 7. wherein the trusted component comprises means 
to %2S£ Z £ Z token to execute a trusted process which indudes generating a digital stature char- 
acterisltc of at toast a portion of the main image. 

9. Adataprccessngsystemaccord^ 
to verify the identity of the secure token. 

10. A data processing system according to any one of daims 4 to 9. wherein the secure token comprises means to 
verify the identity of the trusted component. 

11. Ao^orocessingsystemacw^ 

4S secure token include non-volatile memory. 

12. A data processing system according to daim 11. wherein the trusted component and the secure token each hold 
a respective private cryptographic key in the respective non-volatile memory. 

so 13. A data processing system accordhg to claim 12, wherein the trusted component and the securetoken «ch 

a Sa'certificate induding a public key which forms a private/public key pair with the,r respectve pnvate key. 

14. A data processing system according to daim 1 3. wherein the trusted component and the secure ^^^Z 
p^meanetoreL^ 

ss data and/or verify that the encrypted data was encrypted using the corresponding public key. 

15. Ao^taprocessmgsystem 

is stored by the secure token in compressed form and the trusted component comprises means to decompress 



16 



BNSOCCIO: <EP 1056014A1 I > 



EP1056 014 A1 



10 



20 
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16 A data processing system according to anyone of claims4 to 1 5, wherein the data characterising the trusted image 
is stored by the secure token in encrypted form and the trusted component comprises means to decrypt the data 
and/or verify that the data was encrypted using a corresponding encryption key. 

17 a data processing system accc^^ 
comprises a series of instructions and the trusted component comprises means to interpret the instructions r» order 
to generate the trusted image data. 

18 A data processing system according to claim 6. wherein the trusted component controls the display processing 
,* means to highlight the main image, or portion thereof, by producng one or more of the following Visual effects: 

a border, or an indicator (or indicators) defining a border, characterised by the trusted image and placed at 
1$ least partly around the main image or portion thereof; 

a background pattern characterised by the trusted image forming at least part of the background of the main 

image or portion thereof; . ■ " 

an image characterised by the trusted Image formed within the main image or portion thereof; and** 
a text message characterised by the trusted image formed within the main image or portion thereof. 



19. A data processing system according to any one of claims 3 to 18 ( wherein the display processing means comprises: 

frame buffer memory; . . ^ • . 

a pixel generator to generate pixel data representative of the main image on the basis of the signals received 

2S from the mam processing means; 

a frame buffer refresher to update the pixel data in the frame buffer memory; and . 
a video controlef to repeatedly read the pixel data from the frame buffer memory, generate signals suitable 
for driving the visual display unit and transmit said signals to the visual display unit to display the image, 
and wherein the trusted component comprises means to write the trusted image data, or data derived from 

jo the trusted mage data, to at least a portion of the frame buffer memory in order to combine the further image 

with the main image. 

20. A data processing system according to any one of claims 3 to 19. wherein the trusted component and the user 
feedback processing means are embodied in a single application^pecific integrated circuit or as an appropriately 

35 programmed microcontroller. 

21. A data processing system according to claim 2. wherein the trusted process comprises plural steps and at least 
one of the steps is initiated by user interaction with the trusted component via the secure user input means. 

40 22. A data processing system according to any one of the preceding claims, wherein the trusted component is tamper- 
resistant. 

23. A system comprising: / 

«s main processing means for executing at least one application process; 

means for executing a trusted process in a trusted operating mode and means for generating user feedback 
signals; 

at least one user feedback device; and ^ 
user feedback processing means for receiving said user feedback signals and generating respective signals 
so for driving the user feedback device, 

wherein the means for executing the trusted process comprises means to control the user feedback processing 
means to cause the user feedback device to provide an indication that the data processing system » operaHng 
in a trusted operating mode. 

ss 24. A method for providing a trusted user interface in a data processing system, comprising; 

executing a secure process and generating respective user feedback signals; 

providing user feedback on the basis of the user feedback signals in such a way to indicate that the data 
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